In an application I use, I can easily refactor a current subclass of SplObjectStorage to use composition instead of inheritance https://github.com/phan/phan/blob/v5/src/Phan/Library/Map.php#L30-L40 ( at the cost of a bit of speed) and suppress for now via annotation

But I wonder how many things override SplObjectStorage right now to change key/current to something else in the absense of a native Map type for objects outside of ds/its polyfill.

Aside: Would it make sense to add a new method SplObjectStorage->currentValue() to avoid the need to call $splObjectStorage->offsetGet($splObjectStorage->current())

While I hate the interface that SplObjectStorage exposes (it probably is that way because it predates the non-int/string iterator key support I added in PHP 5.5 or so), your class still clearly violates the API -- if something accepts an SplObjectStorage and is passed your Map instead, it will not behave correctly. So I do think that switching the implementation to use composition would be the right move here.

Never mind, It turns out the functionality I was thinking of already exists as https://www.php.net/manual/en/splobjectstorage.getinfo.php